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Abstract of DE10121819 

Method for controlling access to electronically 
stored data in distributed heterogeneous 
environments in which data access is only 
granted when two or more persons are present 
to authorize the access. A third position for 
access testing is connected between data 
access and data storage positions for testing 
authorization of persons requiring access by 
use of public and private key cryptography. 
The inventive method relates to medical and 
other areas where encrypted data is used. The 
invention relates particularly to accessing of 
patient records. Thus both a patient and doctor 
must be present with their own access chip 
card between medical records can be 
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©Verfahren zur kontextspezifischen Remote-Authentifizierung des Datenzugriffs 
© Die bislang bekannt kryptografischen Verfahren erlau- 

ben mittels nur einer Chipkarte, die entweder vom Arzt 

oder vom Patienten gefuhrt wird, entweder den Zugriff 

auf den gesamten Datenbestand des einzelnen Patienten 

oder auf Daten beliebig anderer Patienten. 

Das neue Verfahren soil dem Arzt nur dann den Zugriff auf 

verschlusselte personenbezogene gesundheitsrelevante 

und auch nur aus der Fachgruppe des fur den Arzt rele- 

vanten Daten ermoglichen, wenn der Patient tatsachlich 

in der Praxis anwensend ist und durch Freigabe seiner 

Chipkarte sein Einverstandnis erklart. 

Sowohl Arzt als auch Patient verfugen uber eine krypto- 

grafische Chipkarte, die aufgrund der verfahrenseigenen 

Verschlusselung der Obertragungswege bei Einfuhren 

beider Karten in ein Lesegerat an einem Rechner in der 

Arztpraxis die Authentifizierung eines Datenzugriffs 

durch mehrere Personen gewahrleistet. 

Das Verfahren eignet sich fur den medizinischen und je- 

den Bereich, in dem datenschutzrelevante Daten zum Ein- 

satz kommen. 
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Beschreibung ^ 

2.1 Technisches Gebiet 

[0001] Zugriffskontrolle auf elektronisch gespeicherte, vertrauliche und schutzbediiftige Daten in verteilter und hete- 
rogener Umgebung, insbesondere auch im Internet 

2.2 Stand der Technik 

[0002] Die dargestellte Erfindung baut im wesentlichen auf der Technologie des Internets sowie kryptographischer 
Verfahren auf, also solcher, die digitale Verschlusselung und Signatur verwenden. 

[0003] Soweit moglich, wird zum Stand der Technik auf die im Internet anerkannten RFC ("Request for Comments") 
Bezug genommen, die z. B. unter http:/ / www.rfc-editor.org abrufbar sind. Diese RFC erfiillen einerseits die Funktion 
anerkannter Standards, andererseits dienen sie auch zur fachlichen Diskussion, so daB neue Entwicklungen hier friihzei- 
tig ihren Niederschlag finden 

2.2.1 Internet-Protokolle 
2.2.1.1 TCP/IP 

[0004] Das Ruckgrat des Internets bildet eine standardisierte Gruppe von Netzwerk-Ubertragungsprotokollen, die hau- 
fig unter dem Kiirzel "TCP/IP" zusammengefaBt werden aber im weiteren Sinne auch beinhalten: 

- Das "Internet-Protocol" (IP, [RFC 791]) weist jedem Rechner im Internet eine eindeutige Adresse aus 4 Bytes zu 
(typische Notation 123.234.56.78) Mehrere Rechner konnen zu Subnetzen zusammengefaBt werden. 

Der Datentransfer erfolgt in Paketen (typ. ca 1 kByte groB) Schnittstellenrechner ("Router") ubernehmen als Ver- 
mittlungsstellen die Verbindung zwischen Subnetzen. MuB ein Paket iiber mehrere Subnetze hinweg transportiert 
werden, wird es von Router zu Router weitergereicht. Im Normalfall ist davon ausziigehen, daB weder Sender noch 
Empfanger die Kontrolle uber alle Router und Subnetze der Ubertragungsstrecke besitzen. Deswegen gilt das Inter- 
net als inharent unsicher und anfallig fur Abhoren und Verfalschen von Daten sowie falsche Identitatsbehauptungen 
("IP-Spoofing") 

Eine neue Version des Intemet-Protokolls (IP-V6, siehe [RFC 1883]) ist in Vorbereitung, hat sich aber noch nicht in 
der Praxis etabliert. 

- Das "Transmission Control Protocol" (TCP, [RFC 793]) setzt auf IP auf und verdeckt die Paketubertragung vor 
den Anwenderprogrammen. Eine Anwendung fordert von TCP eine Verbindung zu einem bestimmten Rechner 
(identifiziert iiber die IP-Adresse) an. TCP stellt der Applikationen "Sockets" zur Verfugung, ein Schnittstellenpaar, 
iiber die sequentieU Daten gelesen und geschrieben werden konnen. Diese Sockets korrespondieren mit denen an 
der Gegenstelle, so daB die Anwendungen auf beiden Rechnem iiber dieses Socket-Paar kommunizieren konnen, 
ohne sich um die darunterliegende Netzwerkstruktur zu kiimmern. 

Um an einem Rechner verschiedene Programme (oder mehrere Instanzen des selben Programmes) unabhangig von- 
einander Verbindungen aufbauen zu lassen, beinhaltet TCP eine "Port- Adresse", die einen bestimmten Socket von 
ggf. mehreren auf einem Rechner idendfizieren kann. 

- Das "User Datagramm Protocol" (UDP, [RFC 768]) ist eine etwas einfachere Alternative zu TCP und setzt eben- 
falls auf IP auf. UDP kennt keine Verbindungen wie TCP, sondern sendet beliebig lange Datensequenzen ("Datag- 
ramme") an die Gegenstelle, ohne auf eine Bestatigung zu warten. UDP verdeckt damit vor allem die Vermittlungs- 
schicht und die Paketstruktur. 

Auch UDP kennt, wie TCP, mehrere Ports auf einem Rechner. 

- Das Domain-Name-System (DNS, siehe [RFC 1034)/[RFC 1035]) ermoglicht die Zuordnung von Netzwerk- 
adressen zu leicht einpragsamen Namen (typische Notation: host.organisation.Iand) und die Uberlagerung einer or- 
ganisatorisch ausgerichteten Gliederung des Netzes Uber die technische Struktur der ff-Adressen mit den Sub-Net- 
zen. 

Das DNS-System ist als verteilte Datenbank mit vielen Zwischenspeichem ausgelegt. Damit wird es (bei korrekter 
Konfiguration) sehr stabil, jedoch anfallig fur MiBbrauch durch bewuBte Fehlkonfiguration ("DNS-Spoofing") in 



2.2. 1 .2 Universal Ressource Locators 

[0005] Universal Ressource Locators (URL [RFC 1738]) ordnen jeder Netzwerkressource (z. B. Rechner, Mail-Konto, 
Textdatei, Bilddatei, Tondatei) einen String zu, iiber den die Ressource im Internet erreicht werden kann. URL enthalten 
typischerweise das verwendete Applikationsprotokoll, den anzusprechenden Server und ggf. weitere Informationen zur 
Spezifikation der Ressource relativ zum Server. 

[0006] Das Konzept der URL wurde im aktuell giiltigen Standard zum "Universal Ressource Identifier" (URL [RFC 
2396]) erweitert, das iiber die Netzerreichbarkeit hinaus Ressourcen eindeutig identifiziert. 

[0007] Eine URL kann auch ein Programm oder Program-Schnittstelle idendfizieren. In diesem Fall kann sie eine 
"query" enthalten, also eine Einheit von Daten, die vom identifizierten Programm interpretiert wird. 
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2.2.1.3 http 

[0008], HTTP ("Hypertext Transport Protocol") setzt als Anwendungsprotokoll auf TCP auf. Aktuell im Einsatz sind 
die Versionen http 1.0 ([RFC 1945]) und http 1.1 ([RFC 2616]). 

[0009] HTTP verbindet einen Client (typischerweise einen WWW-Browser) mit einem Server (einen Web-Server). 5 
Der Client sendet eine Anfrage an den Server, mit der er um die Ubermittlung von Daten bittet. Sowohl der angespro- 
chene Server als auch die Identification der Daten auf dem Server erfolgt iiber eine URL. 

[0010] http erfolgt in isolierten "Request-Response"-Zyklen, zwischen denen keine Verbindung zwischen Client und 
Server aufrecht erhalten wird. Folgende Request-Arten sind gebrauchlich: 

10 

- GET Der Client bittet um die Ubermittlung einer Datei. 

Falls die adressierte Ressource keine Datei, sondem ein Programm ist, kann erganzend noch eine "query", also eine 
Datensequenz, mitgereicht werden. In diesem Fall erstellt das aufgerufene Proramm eine Antwortdatei, die im Re- 
sponse zuriickgereicht wird. 

- POST: Der Client ubermittelt an den Server eine Liste von Variablen mit Werten. POST-Requests sprechen fast 15 
immer Programme auf der Gegenseite an. POST-Requests resultieren typischerweise aus ausgefullten HTML-For- 
mularen. 

[0011] Weitere Request-Arten (PUT, DELETE. . .) sind dagegen wenig gebrauchlich. 

[0012] Das HTTP-Protokoll ermoglicht eine Authentifizierung des Benutzers (d. h. des Browsers gegeniiber dem Ser- 20 
ver) mit Benutzernamen und Passwort. 

[0013] Um http mit Status-Informationen zu erweitem, d. h. dafur zu sorgen, daB ein Server sich an Details eines vor- 
hergehenden Requests des gleichen Clients "erinnem" kann, gibt es zwei gangige Mechanismen. Damit kann das an sich 
statuslose Protokoll das Konzept einer "Session", also einer Reihe von Request-Response-Zyklen mit inhaltlichem Zu- 
sammenhang, implementieren: 25 

- Alle Seiten mit Hyperlinks innerhalb einer Session werden dynamisch generiert. 

Die Session- Varjablen werdpn dabei an die Query aller internen Hyperlink-URLs angehangt (fur GET-Requests) 
bzw. als POST- Variablen, z. B. in versteckten Formularfeldern, hinterlegt. Beim Aktivieren der Links werden diese 
Daten dann vom Browser wieder mit an den Server Zuruckgesandt. 30 

- Eine Erweiterung des Standards ([RFC 2965]-"Cookies") ermoglicht es dem Server, im Response ein Variablen- 
Wert-Paar an den Browser zu senden, das dieser lokal speichert und dann bei jedem Request an den selben Server 
mit ubermittelt. 

35 

2.2.1.4 HTML, XML und Hyperlinks 

[0014] Die "Hypertext Markup Language" HTML wurde zunachst bis zur Version HTML 2.0 ([RFC 1866]) im Rah- 
men der Internets tandards definiert. Inzwischen (mit [RFC 2854]) wurde die Definition an das w3-Konsortium ubertra- 
gen und weiterentwickelt ([HTML401], [XHTMLl], [XML]). 40 
[0015] HTML ermoglicht die formatierte Darstellung von Text (z. B. SchriftgroBe, Absatzformate, Tabellen usw.) so- 
wie das Einbinden beliebiger anderer Dateiformate (z. B. Bilder, Sound, Videos). 

[0016] Daruberhinaus besitzt HTML "Hyperlinks", also Sprungverweise zu anderen Seiten, die im HTML-Quelltext 
mit ihrer URL definiert sind. 

[0017] HTML und HTTP zusammen bilden das WWW (World Wide Web). Durch die in die Seiten eingebettet en Hy - 45 
per links erscheint dem Benutzer der Eindruck, er wiirde auf einer Gruppe von Seiten "sich befinden", obwohl das HTTP- 
Protokoll keinen Verbindungsstatus kennt. Da die URL jeden beliebigen WWW-Server referenzieren konnen, erlaubt die 
geschickte Kombination von HTML-Seiten das Erstellen von "Applikationen", die sich iiber mehrere Server, moglicher- 
weise weltweit verteilt, erstrecken. Durch die Einbindung von Programmen, die auch (iiber HTTP-POST oder eine query 
in HTTP-GET) Benutzereingaben annehmen, laBt sich die Funktionalitat dieser "Web- Applikationen" beliebig erweitern 50 
und viele gangige Benutzeroberflachen einer Software funktional nachbilden. 

2.2.1.5 ssl und tls 

[0018] Die Datenilbertragung in TCP/IP und damit auch in HTTP erfolgt grundsatzlich unverschlusselt und mit be- 55 
grenzter Fehlerkontrolle. Ein boswilliger Angreifer, der Zugang zu geeigneten Routem hat, kann den Datenverkehr ab- 
horen und verfalschen. 

[0019] Um dies zu verhindern, hat die Firma Netscape eine zusatzliche Protokollebene standardisiert, die als ssl (siehe 
[SSL2]) bekannt ist. ssl setzt auf TCP auf und stellt der Applikation wiederum Sockets zur Verfiigung (ist also fur die 
Applikation wahrend der Ubertragung wieder transparent), ermoglicht aber die Absicherung der Ubertragung mit ver- 60 
schiedenen kryptographischen Methoden (symmetrische Schlussel, asymetrische mit ein- oder beidseitiger Authentifi- 
zierung) wie sie weiter unten beschrieben sind. 

[0020] SSL wurde in einer Erweiterung als TLS ([RFC 2246]) in die Internet-Standards aufgenommen. 

2.2.1.6 https 65 

[0021] https, auch S-HTTP genannt, ist in [RFC 2660] spezifiziert und stellt die Implementierung des http-Protokolls 
iiber ssl- bzw. tls-Verbindungen dar. Algorithmen und Schnittstellen zur kryptographischen Infrastruktur sind in den gan- 
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gigen Web-Servern- und -Browsern implementiert. **. 

2.2.1.7 Firewall 

5 [0022] Da das Internet als unschiitzbarer, offentlicher Raum gilt, mussen die Zugange zu Netzen, die vertrauenswiir- 
dige Daten enthalten, entsprechend vor unberechtigtem Eindringen geschiitzt werden - vergleichbar der Pforte an einem 
Werkseingang. Die entsprechenden Vorrichtungen bezeichnet man als "Firewall". Einen Oberblick iiber Techniken und 
Begriffe vermittelt [RFC 2647]. 

to 2.2.1.7.1 Firewall-Prinzipien 

[0023] Firewalls verwenden zwei Grundprinzipien: 

- Paketfilter: Es handelt sich hier urn spezielle Router (vgl. Abschnitt TCP/IP), die zwischen dem extemen und 
15 dem intemen Subnetz stehen und nur nach bestimmten Regeln, ausgehend von Quell- und Zieladressen der Pakete, 

eine Verbindung herstellen, abweisen oder umleiten. 

Paketfilter konnen meist auch IP-Adressen umwandeln ("Network address translation" NAT oder "Masquerading"). 

- Application-Level-Filter: Diese Filter treten gegeniiber den Kommunikationspartnern als Gegenstelle aus und 
werten den Inhalt der ubertragenen Daten aus (z. B. Datentypen, Inhalt, Viren usw.). Je nach Ergebnis der Auswer- 

20 tung wird der Inhalt dann transparent iibertragen, gesperrt, verandert oder auch nur der Transfervorgang protokol- 

liert. 

Neben Sicherheitsuberprufungen konnen diese Filter auch Daten zwischenspeichern und werden dann als "Proxy"- 
Server bezeichnet, wobei der Begriff auch synonym fur Application level filter verwendet wird. 
Application level filter mussen das jeweilige Protokoll (z. B . Mail, ftp, http. . .) verstehen, um den Inhalt analysieren 
25 zu konnen; 



2.2.1.7.2 Firewall-Architekturen 

30 [0024] Die Firewalls-Komponenten werden zu "Firewall-Architekturen" kombiniert. Gangige Grundkonfigurationen 
sind: 

Einfacher Paketfilter: 

(Internet) <Paketfilter>- — (internes Netz) 

35 

Routing findet nur nach festgelegten Regeln statt. 
Es findet keine Inhaltsiiberprufung statt. 
Einfacher Proxy: 

40 (Internet) <Proxy> (internes Netz) 

Es findet kein direktes Routing zwischen intemem Netz und Internet statt. 
Nur Protokolle, die im Proxy implementiert sind, konnen iibertragen werden. 
Dreigliedrige Firewall: 

(Internet) <Paketf ilter> (internes Netz) 

I 

(DMZ) 

+ — <Proxy> 

5Q +— <Web-, Mail-, ... -Server> 

Zweistufige Firewall: 

<Paketf.l>— +—<Paketf.2>— (internes Netz) 

I 

(DMZ) 

+ — <Proxy> 

+ — <Web-, Mail-, . . . -Server> 
[0025] Bei der dreigliedrigen und der zweistufigen Firewall wird zwischen Internet und intemem Netz eine "Entmili- 
tarisierte Zone" (engl. demilitarized Zone = DMZ) als eigenes Subnetz - gleichsam als Sicherheitsschleuse - geschaffen. 
60 [0026] Innerhalb der DMZ gelten niedrigere Sicherheitsanforderungen als im intemen Netz, viele unberechtigte Zu- 
griffe aus dem Internet werden jedoch bereits von der ersten Paketfilterstufe abgefangen. 

[0027] In der DMZ befinden sich typischerweise die Proxy-Server zur S teuerung des Zugriffs zum intemen Netz sowie 
ggf. die offentlichen Server der Organisation. 

65 2.2.2 Kryptographie 



( Internet) 

55 



[0028] Die digitale Kryptographie lost unter Anwendung mathematischer (meist zahlentheoretischer) Verfahren ver- 
schiedene Sicherheitsanforderungen der digitalen Kommunikation wShrend der Speichemng und/oder tjbertragung, ins- 
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besondere 

- Schutz vor unberechtigtem Zugriff von Daten durch Dritte 

- Schutz vor unberechtigter Anderung von Daten 

- Identifikation und Authentifizierung von Sender und Empfanger ... 5 

- iiberprufbare Verbindlichkeit und Unwiderruflichkeit von elektronisch abgegebenen Erklarungen 

[0029] In der vorliegenden Erfindung werden verschiedene etablierte, im Folgenden erlauterte, Verfahren kombihiert. 
[0030] Auf die tatsachlich erreichbare Sicherheit der Verfahren sowie deren EinfluBparameter (Schliissellange, organ- 
siatorische MaBnahmen, physikalische Sicherheit usw.) wird hier nur insofem eingegangen, als sie zum Verstandnis der to 
Erfindung relevant sind. Alle Erlauterungen beziehen sich auf die Annahme nicht korrumpierter Systeme. 

2.2.2.1 symmetrische Verschlusselung 

[0031] Die einfachste Form der verschlusselten Datenubertragung verwendet zur Ver- und Eritschliisselung die gleiche is 
Binarsequenz als Schliissel. Gangige Verfahren sind in [DES] und in [3DES] beschrieben. Eine verschliisselte Nachricht 
kann nur von jemandem, der iiber den gemeinsamen Schliissel verfiigt, gelesen werden. 

[0032] Wollen mehrere Parteien vertraulich miteinander kommunizieren, so besteht entweder (bei Verwendung eines 
gemeinsamen Schliissels) nur ein gemeinsamer vertraulicher Kommunikationsraum oder es muB fur alle Kommunikati- 
onspaare ein eigener Schliissel vereinbart werden. 20 

2.2.2.2 Asymmetrische Verschlusselung 

[0033] Die symmetrische Verschlusselung erfordert eine vorab vorhandene vertrauliche Verbindung, um den Schliissel 
auszutauschen. Dies kann in der typischen elektronischen Kommunikation haufig nicht gewahrleistet werden. Diese Ein- 25 
schrankung umgehen asymmetrische Verfahren. Dabei verfiigt jede Partei iiber einen Teil des Gesamtschlussels, beide 
Teile miissen (nach spezifischen Kriterien des Algorithmus) zusammenpassen ("Schlussel-SchloB-Prinzip"). 
[0034] Eine Nachricht, die mit einem Schlusselteil verschliisselt wird, kann nur mit derri jeweils passenden Teil des 
Schliisselpaares entschliisselt werden. Die Reihenfolge, in der die Schliissel angewendet werden, ist dabei (zumindest bei 
RSA) gleichgiiltig, ebenso konnen mehrere Schliisselpaare nacheinander angewendet werden. 30 

2.2.2.2.1 Algorithmen 

[0035] Bekannte Algorithmen fur asymmetrische Verschlusselung sind Diffie-Hellman ([RFC 2631] [US-Pat No. 
4,200,770]) und RSA ([RSA][RFC 23 13] (als PKCS #1); [US-Pat No. 4,405,829]), DSA sowie Algorithmen auf der Ba- 35 
sis Elliptischer Kurven ([PKCS13]). 

[0036] Soweit nicht anders angegeben, beziehen sich die folgenden Ausfiihrung auf RSA, sind aber weitgehend auf an- 
dere Algorithmen ubertragbar. 

2.2.2.2.2 PubUc-Private-Key- Verfahren 40 

[0037] Bei diesem Verfahren (oft auch mit PKt - Pubfic Key Infrastructure - referenziert) behMlt jeder Teilnehmer an 
einem Kommunikationssystem einen Schliissel des Paares, wahrend der andere an alle anderen Teilnehmer veroffentlicht 
wird. 

45 

2.2.2.2.2.1 Verschliisseln 

[0038] Zum Verschliisseln einer Nachricht gegen unberechtigtes Lesen verschlusselt der Sender mit dem ihm bekann- 
ten offentlichen Schliissel des Empfangers. Nur dieser verfiigt iiber den dazu passenden privaten Schliissel und kann die 
Nachricht entziffern. 50 

2.2.2.2.2.2 Signatur (digitale Unterschrift) 

[0039] Der Sender verschlusselt seine Nachricht mit seinem eigenen privaten Schliissel. Jeder im System kann diese 
Nachricht lesen, da der dazugehorige Schliissel im Paar per Definition offentlich ist. 55 
[0040] Das Lesen mit dem offentlichen Schliissel des Senders gelingt jedoch nur, wenn tatsachlich der private Schliis- 
sel des behaupteten Senders zum Verschliisseln verwendet wurde. Ein boswilliger Drifter, der sich miBbrauchlich als 
Sender ausgeben mochte, aber nicht iiber dessen privaten Schliissel verfiigt, kann dies nicht erreichen. Damit ist die Au- 
thentizitat des Senders gesichert. 

[0041] Der Sender kann eine einmal abgegebene Nachricht nicht verleugnen, wenn sie entziffert werden konnte, da nur 60 
er in der Lage war, diese Nachricht zu erzeugen. 

2.2.2.2.2.3 Trust-Center 

[0042] Public- Key-Systeme erfordern, daB jeder Kommunikationspartner sich auf die Echtheit der von ihm verwende- 65 
ten offentlichen Schliissel verlassen kann. 

[0043] Im einfachen Fall kann das durch einen vorherigen Austausch mit dem Inhaber iiber einen sicheren Kanal er- 
folgen. Der erfofderliche Austauschaufwand steigt jedoch mit dem Quadrat der Teilnehmer und wird deswegen in gro- 

5 
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Beren Systemen zu aufwendig. 

[0044] Fiir diesen Fall kann eine "Vertrauenswiirdige Stelle" (haufige Synonyme: Zertifzierungsstelle, Netznotar, Cer- 
tificate Authority, Trust-Center) zwischengeschaltet werden. Der einzelne Nutzer tauscht nur mit dieser Stelle die offent- 
lichen Schlussel iiber einen sicheren Kanal aus. Das Trust-Center "signiert" den offentlichen Schlussel der Benutzer und 
5 stellt so deren Integritat sicher. 

[0045] Die Verteilung der signierten offentlichen Schlussel ("Zertifikate") kann durch den Benutzer selbst - z. B. mit 
einer Nachricht oder durch Veroffentlichung im Nutzerkreis - erfolgen. 

[0046] Trust-Center-Zertifikate konnen auch kaskadiert werden ("Certificate Chain"), d. h. die Integritatsprufung er- 
folgt indirekt iiber ein Center, das dem betreffenden Nutzer gegeniiber nicht direkt, sondem iiber ein weiteres Trust Cen- 
to ter authentifiziert wurde. Analog konnen zwei zunachst uriabhangige TrusfcCenter sich gegenseitig zertifizieren (Cross 
Certificate) und so die Benutzerkreise vereinigen. 

[0047] Einzelheiten des iiblichen (standardisierten) Verfahrens sind in [X.509] beschrieben. 

2.2.2.2.2.4 Verzeichnis-Dienste 

15 

[0048] Die Veroffentlichung der X-509-Schlussel kann in sogenannten "Verzeichnissen" nach [X.500] erfolgen, wie 
sie spezieU fur das Internet in [RFC 2459] und [RFC 2510] beschrieben sind. 

[0049] Das gangige Protokoll hierfiir ist LDAP [RFC 1777], insbesondere in der aktuellen Version LDAP v3 [RFC 
2251]. 

20 [0050] Diese Verzeichnisse sind als eigenstandige Serverdienste angelegt. Sie ermoglichen die Suche eines Kommuni- 
kationspartners nach verschiedenen Kriterien (unter anderem auch eines weltweit eindeutigen, hierarchischen Namens 
nach X.500- Konvention, auch als DN = "distinguished Name" bezeichnet). Die Hinterlegung von X.509-Zertifikaten in 
LDAP- Verzeichnissen ist Bestandteil der Spezifikation. 

25 2.2.2.2.2.5 Smart-Cards 

[0051] Empfindlichste Angriffsstelle fiir ein PKI ist der Zugriff Unbefugter auf einen privaten Schlussel. Da es sich da- 
bei nur um eine binare Sequenz handelt, kann dieser Schlussel unbemerkt kopiert und von einem Angreifer verwendet 
werden (PC-Wartung, Verwendung in einem fremden Rechner, bosartige Software auf einem PC. . .). 
30 [0052] Um dies zu verhindern, konnen die privaten Schlussel auf unabhangigen Geraten gespeichert werden, die die 
erforderlichen Verschlusselungsoperationen durchfuhren, ohne daB der private Schlussel das Gerat verlaBt, und die kon- 
struktiv uberhaupt nicht in der Lage sind, den privaten Schlussel auszugeben. Unter verschiedenen vorgeschlagenen 
Bauformen hat sich hierzu die "Smart-Card" im Kreditkartenformat etabliert (siehe [ISO 7816]-15). 
[0053] Das Datenblatt eines Beispielproduktes findet sich unter [SecurED 3100]. 

35 

2.2.2.2.2.6 Biometrische Identifizierung 

[0054] Smart-Cards und ahnliche "Security Tokens" konnen entwendet oder vom Inhaber im guten Glauben leichtfer- 
tig iiberlassen werden. Biometrische Verfahren (z. B. Fingerabdruck, Iris-Muster) ermoglichen dagegen die eindeutige 
40 Identifizierung einer Person direkt anhand von Korpermerkmalen. 

[0055] Allerdings ist die Zuverlassigkeit biometrischer Verfahren von der Integritat der priifenden Systeme am Ort der 
zu identifizierenden Person abhangig (vgl. [Biometrics]). In der Remote-Authentifizierung kann ein Angreifer durch ein 
fingiertes System die Reaktion eines echten Systems vortauschen, ohne daB die zu identifizierende Person tatsachlich an- 
wesendist. 

45 [0056] Es bietet sich jedoch an, die Verwendung privater Schlussel auf Smart-Cards (oder anderen Tokens) mit biome- 
trischer Zugriffskontrolle zu sichern, so daB vor jeder Verwendung des privaten Schliissels ein willentlicher Akt des In- 
habers vorausgehen muB (Vergleiche auch [ISO 7816]-11 bzw. zugehorige Normierungsentwurfe). 

2.2.2.3 Hybrid- Verfahren 

50 

[0057] Asymmetrische Verfahren erfordern aufgrund ihrer Komplexitat wesentlich hoheren Rechenaufwand als sym- 
metrische Verfahren. Dies wird durch die Verwendung von (meist sehr mirtimalistischen) Tokens wie Smart-Cards weiter 
verscharft, die im Gegensatz zu modernen Prozessoren in Anwendungsrechnem nur einen sehr begrenzten Datendurch- 
satz aufweisen. 

55 [0058] In vielen Einsatzgebieten werden deshalb verschiedene Verfahren kombiniert, um den Datendurchsatz zu opti- 
mieren. 

2.2.2.3.1 Session Keys 

60 [0059] Ein "Session Key" ist eine Zufallszahl, mit der unter Anwendung eines symmetrischen Verfahrens der GroBteil 
des Kommunikationsinhaltes verschliisselt wird. 

[0060] Das asymmetrische Verfahren (und ggf. das minimalistische Token) braucht dann nur mehr den Session Key 
verschlusseln. Dieser verschlusselte Session Key wird zusammen mit der (symmetrisch) verschlusselten Nachricht iiber- 
tragen. Der Empfanger entschliisselt zunachst den Session Key und mit diesem dann den Rest der Nachricht.. 

65 

2.2.2.3.2 Hash-Funktionen 

[0061] Hash-Funktionen sind sogenannte Einweg-Funktionen, die aus einer langeren Datensegenz einen (im statisti- 
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schen Rahraen) vergleichsweise kurzen, aber eindeutigen Wert (vergleichbar einer Priifsumme) ermitteln, der oft auch 
als "Fingerprint" oder "Hash-Wert" bezeichnet wird. Umgekehrt ist es jedoch nicht moglich, aus der "Priifsumme" auf 
die Daten selber zu schlieBen. 

[0062] Gangige Algorithmen sind bekannt unter den Namen MD2, MD4, MD5 (siehe hierzu [RFC 1321]) oder [SHA]. 
Die Anwendung von Hash-Funktionen findet sich etwa als HMAC unter [RFC 2104]. 5 

2.2.2.3.3 E-Mail und S-MIME 

[0063] Das Verschliisseln und Signieren von elektronischen Nachrichten als E-Mail ist weit verbreitet. Alle gangigen 
e-Mail-Programme verfugen iiber die entsprechende Technologic Die Technologie und Infrastruktur ist ausgereift und 10 
kahn als "Musterlosung" fur die Implementierung komlexer kryptographischer Verfahren gelten. 

[0064] Die Details des Standards "S-MIME" fur verschlusselte tTbertragung von e-Mails im Internet sind in [RFC 
1421], [RFC 1422], [RFC 1423] und [RFC 1424] festgelegt. 

2.2.2.4 Authentifizierungs-Token 15 

[0065] In alien verteilten Rechnersystemen (meist Client-Server-Systeme) ist eine Authentifizierung des Benutzers am 
Zielrechner erforderlich. Im einfachen Fall authentifiziert sich der Benutzer (typischerweise mit Benutzername und Pass- 
wort) an jedem Zielsystem einzeln. Bei groBeren Systemen fuhrt das zu einem erheblicheri Administrationsaufwand im 
System und zur Verwirrung der Benutzer mit vielen Passwortern. 20 
[0066] Authentifizierungsverfahren mit einem eigenstandigen Priifsystem sind seit langerem bekannt. Bei diesen Ver- 
fahren existiert neben der datenanfordemden Stelle (z. B einem Arbeitsplatzrechner, also dem Client) und der datenhal- 
tenden Stelle (z. B. einem Fileserver) ein eigener Authentifizierungsrechner. Der Client meldet sich zunachst am Authen- 
tifizierungsrechner an, nur dieser muB in der Lage sein, die Identitatspiifung fur jeden Nutzer vorzunehmen. Er erstellt 
dann ein "Token" oder "Ticket" nach kryptographischen Methoden, das an den Client zuriickubermittelt wird. Mit die- 25 
sem Token kann der Client sich dann an verschiedenen Datenservern authentifizieren. 



2.2.2.4.1 Kerberos 



[0067] Als Prototyp der Token-basierten Authentifizierung gilt das am MIT entwickelte Kerberos, das in seiner aktu- 30 
ellen Version V5 als Internet-Standard ([RFC 1510]) etabliert ist. Eine Kerberos- Variante wird unter anderem auch im 
Microsoft-Betriebssystem WINDOWS 2000 eingesetzt und lost dort einen proprietaren Mechanismus, wie er in NT 4 
verwendt wurde, ab. 

[0068] Kerberos verwendet symmetrische Schliissel fur jeden Benutzer, die in den Authennfizierungsrechnem abge- 
legtsind. 35 

2.3 Problemstellung 

2.3.1 Konkrete Aufgabenstellung im medizinischen Umfeld 

40 

[0069] Ein Arzt behandelt einen Patienten und braucht dazu Daten (z. B. Befund, Rontgenbild. . .); die von einem Drit- 
ten (z. B. einem Krankenhaus, einem Labor oder einer anderen Arztpraxis) - "Datenhalter" genannt - gespeichert wer- 
den. 

[0070] Verschiedene Rechtsvorschriften, Berufstandsregeln, Vertrauenserwartungen der Patienten, Vertrauenskonstel- 
lationen usw. verpflichten den Datenhalter, nur berechtigten Personen einen Zugriff auf definierte und von den jeweiligen 45 
Personen abhangigen Bereich der Daten zu gewahren. 

[0071] Erforderliche Informationen, die der Datenhalter braucht, um Zugriffsentscheidungen zu treffen, sind etwa: 

- Ist die anfordernde Person tatsachlich Arzt und wenn ja^ in welchem Fachgebiet? 

- Ist der Patient, den die Daten betreffen, anwesend und hat er seine Zustimmung erteilt? 50 

- Ist sich der Patient iiber die gespeicherten Daten im Einzelnen bewuBt (will er z. B. einem Arzt, der ihn im Auf- 
trag einer Versicherung untersucht, offenbaren, daB es umf angreiche Daten aus einer Herzklinik gibt)? . 

- Gibt es eine besondere Vertrauensstellung zwischen der anfordernden Stelle und dem Datenhalter, z. B. aufgrund 
besonderer vertraglicher Regelungen? 

55 

[0072] Die Anwendung der gebotenen hochsicheren tjbertragungsverfahren nach dem Stand der Technik iiberfordert 
regelmaBig die beteiligten Parteien, so daB die Absicherung der Obertragung an Dritte ("sicherheitsvermittelnde Stelle") 
auszulagern ist, die jedoch keine Berechtigung haben, die Daten selber zu lesen. 

[0073] Kosten- und Effizienzkriterien erfordern, daB auf Seiten des Datenhalters und der sicherherheitsvermittelnden 
Stelle die Abwicklung ohne direkte EinfiuBnahme von Menschen erfolgt. 60 
[0074] Neben der reinen Authentifizierung der beteiligten Personen konnen noch weitere Informationen des Anforde- 
rungskontextes erforderhch werden, die ggf. iterativ abgefragt werden miissen. 

2.3.2 Verallgemeinerung der Problemstellung 

65 

[0075] Die dargestellte Losung betrifft die Verschliisselung der "Dbertragungswege und beinhaltet keine Einschrankung 
der Daten selber, deswegen kann der Einsatz auch auBerhalb des medizinischen Umfeldes erfolgen. 
[0076] Damit kann die Aufgabenstellung erweitert werden: 
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Es soli einem datenverarbeitenden System ermoglicht werden, bei einem angeforderten Datenzugriff Informationen iibef . 
den Kontext des beabsichtigten Zugriffs, insbesondere mehrerer beteiligter Personen, des Zeitpunktes, und ggf. weiterer 
anwendungsspezifischer Informationen zu erhalten. Der Betrieb des Zugriffskontrollsystems soil dabei von der Daten- 
haltung entkoppelt werden konnen. 

5 

2.4 Wesen der Erfindung 

[0077] Es werden die bekannten Sicherheits- und Authentifizierungsverfahren dergestalt kombiniert, daB zur Authen- 
tifiziemng eines Datenzugriffs mehrere Personen zustimmen miissen, weitere Informationen aufgenommen werden kon- 
10 nen und die Rollen verschiedener Schritte im Authentifizierungsprozess raumlich und datentechnisch weitgehend ent- 
koppelt sind. 

[0078] Damit wird es moglich, die Verteilung der Verantwortung fur Teilbereiche ortlich und organisatorisch zu tren- 
nen und Systeme auf unterschiedlichen Plattformen zu integrieren. 

15 2,5 Gewerbliche Anwendbarkeit 

[0079] Alleine im Gesundheitswesen wird von Fachieuten ein enormes Rationalisierungspotential sowie eine Quali- 
tats- und Serviceverbesserung vorhergesagt, wenn die Kommunikation zwischen mehreren Arzten, die einen Patienten 
behandeln, verbessert wird. 

20 [0080] Die elektronische Kommunikation, wie sie in vielen anderen Bereichen heute bereits iiblich ist, konnte dafur ei- 
nen wichtigen Beitrag leisten, scheiterte bisher aber an einer Infrastruktur, die einerseits die erforderlichen Sicherheits- 
anforderungen erfullt und andererseits fiir die betroffenen Akteure handhabbar bleibt. 
[0081] Die beschriebene Erfindung kann als Grundlage fur diese Sicherheits-Infrastruktur dienen. 
[0082] Weitere Anwendungsfalle ergeben sich z. B. in der Rechtspflege, der Wirtschafts- und Steuerberatung, der Per- 

25 sonalvermittlung und -beratung, dem Versicherungswesen, dem Handel mit Kauferprofilen oder dem Finanzwesen. 

2.6 Vorteile 

[0083] Bisherige Losungen auf bekannten Standards ermoglichen immer nur die Authentifizierung einer Person (z. B. 
30 des Arztes). Dieser hat dann Zugriff auf einen wesentlich groBeren Datenbestand, nicht nuf auf den jeweiligen Patienten, 
was hier eingeschrankt werden kann. Durch die Ubertragung weiterer Kontextdaten konnen beliebig komplexe Sicher- 
heitsphilosophien implemendert werden. 

[0084] Ein weiterer Vorteil der beschriebenen Losung ist die Modularitat. Es konnen damit einfach bestehende Sy- 
steme verschiedener Datenhalter und Datenverwender mit einfachen Schnittstellen kombiniert werden zu einem sicheren 
35 Datenaustauschnetzwerk. 

2.7 Ausfiihrungsbeispiel 

siehe Abschnitt 3 

40 
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W3C Recommendation; 6 October 2000 
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3.1 Vorbemerkung 

[0085] Das beschriebene Ausfuhrungsbeispiel beruht auf der konkreten Aufgabenstellung im medizinischen Kontext 
(vgl. Erlauterungen zum Patentantrag) und verwendet deshalb die entsprechenden Begriffe "Arzt", "Patient" usw. Die zu- 
grunde liegende Aufgabenstellung besteht darin, dem Arzt Zugriff auf vertrauliche Daten des Patienten, den er gerade 
behandelt, zu gewahren, und zwar nur zu diesem Patienten und nur in einem Umfang, wie es seiner standesrechtlichen 
Zulassung und der Einwilligung des Patienten entspricht (vgl. Anspruch 1). 

[0086] Mogliche Erweiterungen und Varianten des Verfahrens sind teilweise (in Kursivdruck) im Text sowie im letzten 
Abschnitt beschrieben, ergeben sich aber insbesondere aus den Patentanspriichen. 

3.2 Architektur 

[0087] Die an einem Gesamtsystem beteiligten Komponenten sind in der Zeichnung 1 skizziert. 
[0088] Es wird fur die drei wesentlichen Bestandteile - Anforderungsstelle, Zugriffskontrolle und Datenhaltung - im- 
mer im Singular gesprochen. In einem ausgebauten System konnen naturlich von all diesen Stellen mehrere Instanzen 
auftreten, die auch miteinander weiter vernetzt (z. B. iiber HTML-Links) sein konnen. 

3.2.1 Arbeitsstation zur Zugriff sanforderung 

[0089] Am Arbeitsplatz des Arztes befindet sich ein PC mit einem Standard- Web-Browser. Es wird angenommen, daB 
der Zugriff auf die Daten vorzugsweise iiber HTML/http erfolgt, da damit eine einfache Integration und Standardisierung 
erreicht werden kann. 

[0090] Erganzend kann an der Arztpraxis auch ein eigenes Praxis-Managent-System ("PMS") vorliegen, das entweder 
iiber den Browser oder unabhangig, aber sinnvollerweise auch iiber http/https Daten nach Freigabe abrufen kann. Die In- 
tegration des PMS ist jedoch fur das Verstandnis der vorliegenden Erfindung unwesentlich. 
[0091] Die Zuverlassigkeit des PCs und der Praxissoftware unterliegt der Kontrolle des Arztes; 
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3.2.2 Schlusselkarten der Benutzer 

[0092] Sowohl Arzt als auch Patient verfiigen iiber eine Smart-Card mit dort abgelegtem privatem Schlussel und inte- 
griertem Kryptoprozessor (nach Anspruch 7 und 8). 
5 [0093] Fur Arzte gibt es dafiir bereits einen etablierten Standard ("health professional card" - HPC), der diese \forga- 
benerfullt. 

[0094] Fur die Patienten gibt es keinen definierten Standard. Die Karte des Patienten sei mit einem Fingerabdruckleser 
ausgestattet, der vor jeder Verschliisselungsaktion ausgelost werden muB und dafiir sorgt, da6 vor jeder Schliisselverwen- 
dung eine explizite, personfche WillensauBerung des Patienten vorliegt (Anspruch 9 und 10)!. 
10 [009S] Die Arbeitsstation des Arztes muB mit geeigneten Lesegeraten ausgestattet sein, um die Smart-Cards (gleich- 
zeitig oder nacheinander) anzusteuem. 

3.2.3 Zugriffskbntrollsystem 

15 [0096] Das Zugriffskontrollsystem ("Access Management Hub") befindet sich raumlich und organisatorisch unabhan- 
gig von Arztpraxis und Datenbank. 

[0097] Es ist iiber eine Firewall mit dem Internet verbunden. 

[0098] Es verfugt iiber eine Datenbank der offentlichen Schlussel aller registrierten Arzte sowie aller Zertifizierungs- 
stellen, die zur Registrierung von Patienten befugt sind (Access directory). 
20 [0099] Diese Datenbank kann am Standort der Zugriffskontrollstelle selbst liegen oder iiber geeignete DireCtory-Pro- 
tokolle (z. B. LDAP) ganz oder teilweise von anderen Standorten importiert werden (vgl. Anspruch 21 ff). 

Erweiterung 

25 [0100] Werden - abweichend vom Bild - mehrstufige Zertifikatsketten verweridet (vgl. Anspruch 18), reicht es fur die 
priifende Stelle aus, die Zertifikate der untersten Ebenen der verwendeten Ketten vorzuhalten. In diesem Fall mussen die 
vollstandigen Zertifikate einschlieBlich ggf. aller Zwischenzertifikate auf den Smartcards der zu authentifizierenden Per- 
sonen abgelegt sein und als Bestandteil des Authentifizierungsantrages mit iibertragen werden (Anspruch 20). 
[0101] Die Zugriffskontrollstelle stellt das empfindlichste System in der Sicherheitskette dar und befindet sich deshalb 

30 in einem eigenstandigen hochsicheren Bereich eines spezialisierten Dienstleisters ("Access security provider"). 

Erweiterung 

[0102] Alle Vorgange konnen - z. B. zur Beweissicherung in Streitfallen - mitprotokolliert werden ("Access Log"). 

35 

Erweiterung 

[0103] Die Zugriffskontrollstelle kann bereits Informationen vorhalten, wo welche Daten iiber einen Patienten abge- 
speichert sind ("Location directory") 

40 

3.2.4 Datenspeicher 
[0104] Die Datenbank mit Patientendaten wird als bestehend angenommen. 

[0105] Die Schnittstelle fur Femzugriff sollte moglichst nahe an die Anforderung browsergestutzter Systeme kommen, 
45 was beispielsweise durch die Anwendung der XML- Version des intemationalen Patientendatenstandards "hl7" erreicht 
werden kann. 

[0106] Der Datenspeicher ist aus dem Internet nicht direkt erreichbar (Anspruch 39). 

3.2.5 Freigabesystem 

50 

[0107] Das Freigabesystem ("Zugriffskontrollserver") befindet sich hinter einer Firewall (Anspruch 39) am Standort 
des Datenhalters, z. B. eines Krankenhauses ("Hospital or other maintainer of health information services"). 
[0108] Im Beispiel wird angenommen, daB die Datenbank selber Informationen im XML-Format liefert, das von den 
gangigen heutigen Browsem nur eingeschrankt gelesen werden kann. In diesem Fall kann das Freigabesystem eine t)ber- 
55 setzung ("XSLT-Processbr") in Standard-HTML vornehmen. Es kttnnen aber auch XML-Daten direkt durchgereicht 
werden (nach erfolgter Freigabe) oder, wenn die Datenbank selbst HTML-Format liefem kann, kann auch dieses nach 
Priifung weitergereicht werden. Durch diese Variationsmoglichkeiten ergeben sich breite Anpassungsmoglichkeiten an 
vorhandene Systeme. 

[0109] Fur die Implementierung kann jede gangige Programmierumgebung verwendet werden. Java-Servlets bieten 
60 beispielsweise die erforderlichen HTTP-Schnittstellen und sind offen fiir die wichtigen Netzwerk-, Krypto- und XML- 
Bibliotheken. 

[0110] Der Zugriff auf den Datenspeicher erfolgt typischerweise nochmals iiber eine Paketfilterung auf IP- und Port- 
Ebene (dicke schwarze Linie mit Lochem), so daB sich das Freigabesystem in einer DMZ zwischen zwei Paketfiltem be- 
findet (vgl. "Stand der Technik/Firewall" sowie Anspruch 39 und 40). Altemativ, aber mit gleicher Funktionalitat, erfolgt 
65 die Kommunikation zwischen Firewall und Datenbank iiber ein anderes Protokoll als TCP/IP, so daB ein direktes Routing 
aus dem Internet effizient verhindert wird. 

[0111] Das Freigabesystem erhalt seine Zugriffskontrollinformationen aus der Datenbank (Anspruch 30 flf, im Bild an- 
gedeutet mit dem dicken Doppelpfeil), wobei die genaue Implementierung davon abhangt, wie diese Informationen vor- 



12 



DE 101 21 819 A 1 



liegen. Eine einfache Moglichkeit besteht darin, daB die Zugriffskpntrollinformationen zusammen mit den Daten (An- 
spruch 32), etwa im HTML-Header als Meta-Tags (Anspruch 33) oder als spezifische Felder in einem XML-Format (An- 
spruch 34) abgelegt sind. 

3.2.6 Dateniibertragung 5 

[0112] Die Dateniibertragung erfolgt im Beispiel ausschlieBlich iiber das Internet (vgl. Anspruch 2), also zunachst un- 
sicher. 

[0113] Alle Verbindungen werden iiber ssl, also verschliisselt, realisiert (Anspriiche 16, ggf. 21, 26/27, 36). Dabei er- 
folgt immer eine wechselweise Authentifizierung (also sowohl Server gegeniiber Client als auch Client gegenuber Ser- to 
ver), um einen hochstmoglichen Schutz gegenuber Angreifern zu gewahren. 

[0114] Die Ablaufe sind so gestaltet, daB das einfache http-Protokoll mit Request-Response-Zyklen ausreicht. Somit 
kann an alien Verbindungen das standardisierte https-Protokoll (http iiber ssl) verwendet werden (Anspriiche 17, 27, 36). 
[0115] Erweiterungen und Variationen der Netzwerkprotokolle sind an dieser Stelle zwar denkbar, versprechen aber 
keinen funktionalen Vorteil. 15 

3.2.7 Trust-Center 



[0116] Im beschriebenen Ablauf sind eine Reihe von asymmetrischen Schliisselpaaren im Einsatz, und zwar minde- 
stens: 

- Schliissel des Arztes auf der HPC (Anspruch 1) 

- Schliissel des Patienten (Anspruch 1) auf seiner biometrisch gesicherten (Anspriiche 9, 10) Karte 

- ssl-Client-Schliissel des Arzt-Arbeitsplatzes (Anspruch 16 und 35) 

- ssl-Server-Schliissel des Zugriffskontrollsystems (Anspruch 16 und 26) 

- ssl-Server-Schliissel des Freigabesystems (Anspruch 26 und 35) 

- ssl-Client-Schliissel des Zugriffskontrollsystems (nach Anspruch 24 und 26) und/oder des Freigabesystems (nach 
Anspruch 25 und 26) 

[0117] Diese Schliissel werden sinnvollerweise von einem Trust-Center als spezialisiertern Dienstleister generiert und/ 
oder in ihrer Echtheit bestatigt (Anspruch 10). Inwieweit hierbei ein einziges oder mehrere Trust-Center verwendet wer- 
den, und ob diese organisatorisch an eiher der dargestellten Stellen, z. B. der Zugriffskontrollstelle, angelagert sind, ist 
aus technischer Sicht nicht von Belang. 



3.3 Ablauf aus Benutzersicht 
3.3.1 Antragssoftware 



[0118] Wenn der Arzt seine Behandlung aufnimmt, ladt oder aktiviert er eine geeignete "Antrags-Software" (z. B. ein 

im Browser lauffahiges Java-Applet; "Authorisierungs-Applet" im Bild), die auf seinem Rechner vorinstalliert ist oder 40 

die er aus einer vertrauenswiirdigen Quelle (z. B. auch der Zugriffskontrollstelle) beziehen kann. 

3.3.2 Freigabeantrag 

[0119] Die Antragssoftware verlangt nun nach den Identitatsbeweisen, also etwa den Smart-Cards von Arzt und Pa- 45 
tient. Die endgiiltige Zustimmung (nach Anspruch 1) erfordert noch die Freigabe des Schlussels auf den Karten, z. B. 
durch ein Passwort bei der HPC und durch den Fingerabdruck bei der biometrischen Patientenkarte. 
[0120] Nach Absenden des Freigabeantrags (nach Anspruch 3) an die Zugriffskontrollstelle meldet diese entweder ei- 
nen Authentifzierungsfehler oder einen Hyperlink zum nachsten Schritt. 

[0121] Der in Zeichnung 2 auf Seite 52 dargestellte Biidschirmabzug zeigt eine Pilotversion eines solchen Freigabe- 50 
applets, bei dem die Smart-Cards durch Binarsequenzen ersetzt sind, die iiber die "Windows-Zwischenablage in entspre- 
chende Fenster eingefugt werden ("paste doctor's/patient's key here"). 

[0122] Die Freigabe selbst erfolgt in der Pilotversion durch Passworter, was im Bild beim Patienten bereits erfolgt ist 
("open") und fur den Arzt noch abgefragt wird ("please enter password") 

55 

3.3.3 Datenauswahl 

[0123] Im Beispiel wird angenommen, daB die Zugriffskontrollstelle bereits iiber eine Liste von zum Patienten verfiig- 
baren Daten verfiigt. In diesem Fall kann an den Arbeitsplatz des Arztes eine entsprechende Liste als HMTL-Seite mit 
Hyperlinks versandt werden, wobei die Hyperlinks auf die jeweiligen Freigabeserver verweisen. 60 
[0124] Arzt und/oder Patient wahlen (ggf. gemeinsam) die abzurufenden Daten aus ("weitere Kontextinformationen" 
nach Anspruch 1). 

3.3.4 Datenabruf 

65 

[0125] Im Idealfall verhalt sich das nun geoffnete System gegenuber dem Arzt wie ein Satz von HTML-Seiten, er kann 
also im Bestand der Patientendaten mit seinem Web-Browser "surfen" (Anspruch 41 ff) und ggf. wichtige Informationen 
in sein eigenes Praxisdatensystem "downloaden". 

13 
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Erweiterung 

[0126] Bei geeigneter Datenstruktur konnen dabei auch Querverweise zwischen verschiedenen Datenbestanden auftre- 
ten. Ggf. wird das System nach einer erneuten Authentifizierung verlangen, wenn etwa der Bereicb einer anderen Zu- 
griffskontrollstelle betreten werden soli oder der Patient weitergehende Freigaberechte fur besonders vertrauenswiirdige 
Daten oder weitere Rechte (z. B. Schreibzugriff) erteilen soli. 

3 A Zusammenspiel der kryptographischen Komponenten 

[0127] Die erforderlicheh kryptographischen Ablaufe sollen bei erfolgreicher Authentifizierung weitgehend im Hinter- 
grund ablaufen. Lediglich bei einem Authentifizierungsfehler sollen Fehlermeldungen soweit aussagefahig sein, daB Be- 
dienungsfehler behoben werden konnen. Allerdings diirfen Fehlermeldungen keine wertvollen Informationen an poten- 
tielle Angreifer offenbaren oder bereits vertrauenswurdige Daten (bzw. deren Existenz) preisgeben (falsch ware z. B. 
"Sie sind nicht berechtigt, auf den Datenbestand der Sucht-Heil-Klinik zuzugreifen"). 

3.4.1 Schlussel 

[0128] Das Format der Schlussel entspricht dem X.509-Standard, wie es von gangigen Internet-Browsern verstanden 
wird. (Beispiel: siehe Zeichnung 3 ) 

[0129] Die Schlussel fur https miissen dabei direkt vom Browser verstanden werden konnen. Fur die Smart-Card- 
Schlussel ist dies nicht unbedingt notwendig, da sie iiber die Authentifizierungssoftware angesprochen werden. Die Ver- 
wendung standardisierter Formate ermoglicht aber den ZugrifF auf vorhandene, getestete Softwarebibliotheken zur Er- 
zeugung und Verarbeitung der kryptographischen Daten. 

[0130] Ein Schliisselpaar, das aus einem Browser im PKCS#12-Format ([PKCS12]) exportiert wird, stellt sich zu- 
nachst folgendermaBen dan 



BEGIN RSA PRIVATE KEY 

Proc-Type: 4 , ENCRYPTED 

DEK-Info: DES-EDE3-CBC, FD4DCOA4 919C7342 

S ^fY P S? DxWg ^ 1TDMIimHKo ^ erMWzalNeI2el D 8E /uRf89fNNRq0oTVh 

lhPltydbSKnDUpgD5sMhQUy 2 urdsD4dWleqnF503RJ2t7e8rZk9kbAauQ02ggVRR 

QP^" xn2 Gp0FGHlyj9AymjyE/se7kyaZaIV O dgQI7Yl/dGBKX/peJEwintwkQMXlV 

BG02JwyedknWcYM6t0hFAmRX9GL2bh/MhZEBQP80cUQhVBvV0oek9LIlW84Y+czp 

QdwmrPzmNgScRr5cy6Hw/3TleYvasdZufL38LwMpxwa3m0ccTXgNr8w4wcGOMfA6 

kVzbZMxunLPYQS5FekxLn8K7Ce/WKXEuinTvLGlVaAd6mhE9vKKBlwklVUluIlz01 

F2LOur/Yg5gX8cLkC9L6cY7B8LSJ5z5C9HJG3F4553o= 

END RSA PRIVATE KEY 

Bag Attributes 

friendlyName: Benjamin Blymchen's IP-Web ID 

localKeylD: 3C E3 30 30 57 B7 49 A9 CI A8 AA CO 04 B3 48 CC EC F5 24 02 
subDect=/C=de/ST=ppp/L=Bibberberg./0=Interessenvereinigung sprechender 
Elefanten/CN=Ben] amin BlXxFCmchen 

issue f"^. /C=de/ST=demo/0 = Ip - w eb/OU=demo/CN=IP-Web Demo Patients CA 
-■ BEGIN CERTIFICATE- 



^i? FDCC ^ 2gAwlBA ^ IEOrTuu ^ ANB ^ k ^ hkiG9w0BA QQ F ADBeMQswCQYDVQQGEwJk 
ZTENMAsGAlUECBMEZGVtbzEPMA0GAlUEChMGSVArV2ViMQ0wCwYDVQQLEwRkZWlv 
^ AW S g P VQQDExdJUC1XZWIg RGVtbyBQYXR P ZW5GcyBDQTAeFw0wMTAzMTgwMDAw 
MDBaFw0wMzAzMTgyMzU5MDBaMIGCMQswCQYDVQQGEwJkZTEMMAoGAlUECBMDcHBw 
MRMwEQYDVQQHEwpCaWJiZXJiZXJnMTQwMgYDVQQKEytJbnRlcmVzc2VudmVyZWlu 
aWdlbmcgc3ByZWNoZW5kZXIgRWxlZinFudGVuMRowGAYDVQQDFBFCZW5qYWlpbiBC 
bPxtY2hlb j BcMA0GCSqGSIb3DQEBAQUAA0sAMEgCQQDgnGf aZx6YNtrBn2islWL0 
« P f^f O7UBM+pBNUoGgnM/YVFelihLK3vaf8D0 P Mn I6iqpqfbsbTXPDP87yTsBdV 
AgMBAAEwDQYJKoZIHvcNAQEEBQADgYEAwS+fUrinuGFzKd6E05fHqg2o4M;innA6 
Z J "f/? Yefxi ^ AWw Q S9< 3 CL Q nMJ03 aiCdspFL5WVH3QKbAXWHdJJsjOSTtj/5pUqa 

241KFsP/nDP H51f6DZX ° FDbllZOjiU3Y5Dkbp7a ^ 
END CERTIFICATE 



[0131] Die wesendichen Komponenten sind der private Schlussel ("BEGIN/END RSA PRIVATE KEY") sowie das 
X.509-Zertifikat mit dem offentlichen Schlussel ("BEGIN/END CERTIFICATE"). Beide Bestandteile sind in der Dar- 
stellung base-64-kodiert, was jedoch nur der Obertragbarkeit binarer Daten und nicht der Zugriffssicherheit dient. Die 
weiteren Angaben dienen nur der internen Organisation des PKCS-12-Formates. 

[0132] Dieses Format entspricht im Wesentlichen auch der internen Darstellung auf einer Smart-Card. 

[0133] Das Zertifikat, das die Echtheit des Schlussels durch Trust-Center bestatigt, hat (nach base-64-Dekodierung) 

folgende Struktur (nach [X.509]). 
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Certificate: 
Data: 

Version: 3 (0x2) 

Serial Number: 984936122 (0x3ab4eeba) 
Signature Algorithm: md5WithRSAEncryption 

Issuer: C=de, ST=demo, 0=IP-Web, 0U=demo, CN=IP-Web Deno Patients CA 
validity 

Not Before: Mar 18 00:00:00 2001 GMT 
Not After : Mar 18 23:59:00 2003 GMT 
Subject: C=de, ST=ppp, L=Bibberberg, 

0=lnteressenvereinigung sprechender Elefanten, 
. CN=Benjamin Bl\xFCmchen 
Subject Public Key Info: 

Public Key Algorithm: rsaEncryption 
RSA Public Key: (512 bit) 
Modulus (512 bit) : 

00:e0:9c:67:da:67:le:98:36:da:cl:9f :68:ac:95: 
62:f4:12:96:8d:6d:23:bb:50:13:3e:a4:13:54:a0: 
6a:a7:33:f6:15:15:ed:62:84:b2:81:bd:a7:fc:0f : 
4a: 4c: 84 :9e:a2:aa: 9a: 9f : 6e : c6 : d3 : 5c : f 0 : cf : f 3 : 
bc:93:b0:17:55 
Exponent: 65537 (0x10001) 
Signature Algorithm: md5WithRSAEncryption 

Cl : 2f : 9f : 52 : b8 : a7 : b8 : 61 : 73 : 29 : de : 84 : d3 : 97 : C 7 : aa : Od: a8 • 
eO : cf : 8 8 : 9e : 70 : 3a : cc : 95 : f 7 : 6b : b4 : 58 : 7 9 : f c : 62 : 8c : 05 : b0 • 
41:2f :6a:08:b4:27:30:9d:37:6a:20:9d:b2: 91 ( :4b:e5: 65-47- 
dd:02:9b:01:75:87:74:92:6c:8c:e4:93:b6:3f : f 9 : a5 : 4a • 9a • 
f9:al:8b:d.5:7d:12:18:dl:3d:lf :9d:5f : e8 : 3c :d7 : aO : 50 : db - 
d7 : 5 6 : 4 e : 8e : 25 : 37 : 63 : 90 : e4 : 6e : 9e : da : 25 : 66 : de : 71 : 89 : ed • 
fe: 3a : ab : a f :.bl : 06 : ac : 2f : 4e :d9 : 36: 94 : db : 8d: 4a : 16 : c3 : f f ; 
9c:38 



- "Subject" ist dabei der Name der zu identifizierenden Person 35 

- "issuer" das Trust-Center, das die Echtheit bestatigt (vgl. Anspruch 10a). 

.- Validity (Gultigkeitsdatum) und Seriennummer sowie Version und Algorithmen sind weitere Organisationsbe- 
standteile nach X.509 

- Der offentliche Schliissel ("RSA public Key") ist wesentlicher Bestandteil des Zertifikats 

- Die Signatur (eingeleitet mit der Angabe des Algorithmus), die die Echtheit des Schliissels bestatigt, schlieBt das 40 
Zertifikatab. 

[0134] Der private Schliissel ist in einem passwortgeschiitzten "Key Bag" untergebracht, d. h. zusatzlich zur base-64- 
Dekodierung ist noch eine Entschliisselung mit dem Passwort erforderlich. 

[0135] Erst nach Offnen des "Key Bag" durch Passworteingabe (oder Fingerabdruck) eroffnet sich die interne Struktur 45 
des privaten RSA-Schliissels, wie er zur Verwendung erforderlich ist: 



50 



60 



65 
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Enter . PEM pass phrase: 
Private-Key: (512 bit) 
modulus : 

00:e0:9c:67:da:67:le:98:36: da : cl : 9f : 68 : ac : 95 : 
62: f4 : 12 : 96 : 8d : 6d : 23 : bb: 50 : 13 : 3e : a4 : 13:54 :a0: 
6a:a7 : 33: f6: 15:15 :ed:-62:84 : b2 : 81 : bd : a7 : f c : Of : 
4a: 4c: 84 : 8e:a2: aa: 9a : 9f : 6e : c6 :d3: 5c: f 0: cf : f 3 • 
bc:93:b0:17:55 

publicExponent: 65537 (0x10001) 

pri vateExponent : 

00:ae:e8:bd: 6a: f 3 : 60 : 7c : d2 : 42 : ba : 03 : 04 :05:59: 
73:ac: 73: 89: 2f : ea : ec : a7 : 62 : 2d : 0a : 5b : c4 : fd: e2 • 
ca:0b:17:53:ld:3e:d2 : a4 : 3c : 81 : 93 : 4d: 89: 82 : 37 : 
23: 28 :1b: 7c: 9f : b6 : 8e : 2a : eb : 4 9 : e3 : b5 : f 1 : cl : 1 8 : 
eb:e8:be:b4:21 

primel: 

C0:f5:0b:2c:25:3d:a3:95:lf : 9b : ee : 8b : 83 : b2 : 57 : 
03:2e:d8:3c:85:cb:6c:50:00:le:57:a7: la:37:f4: 
0a:5d:c9 
prime2: 

00:ea:a7:5b:lc:d3:a0:73:cc:3a:63:ca:33:73:e2: 
f3:cd:e6:4b:3d:5b:3c:f6:bl:37:37:98:4e:34:3d: 
c2: 43: 2d 
exponentl: 

00:d2:3b:c2:a5:34:cb:fa:ee:02:97:57:a5:26:c5: 
d6:5a:43:75:31:89:04:a5:62:64:a5:e9:lc:ea:72: 
7a:ce:59 
exponent2 : 

2f :06:a7:ld:d9:d3:98:21:5f :ba:4b:f5:8f :cd: £5: 
ea:57:b2:d0:73:0e:7e:a9:f9:54 :ec:f3:0f :49:29: 
3b: 69 
coefficient: ■' 

4 9:09:37:c9:09:26:23:d4:le:9c:58:b4:eb:ll:38: 
a6:41:32:fe:21:a7:6e:07:21:c9:4b:34 :57:11: 43: 
74:60 



[0136] Fur Schlussel, die auf Smart-Cards abgelegt sind, ist diese Struktur des pri vaten Schliissels von auBen nicht zu- 
ganglich (auch nicht nach Freigabe). Alle zu verschliisselnden Daten miissen in die Smart-Card ubertragen werden, wer- 
den dort (nach Freigabe) verschlusselt und wieder aus der Smart-Card ausgelesen. 

40 

3.4.2 Authendfizierungs-Applet 
[0137] Das Authentifizierungs- Applet ubemimmt folgende Funktionen: 

45 - Erstellen eines zufallig generierten Session Keys (Anspruch 4 und 11) 

- Ermitteln der aktuellen Systemzeit (fur Anspruch 4) 

- Ermitteln der Idendtat von Arzt und Padent (Anspruch 1 - z. B. "Distinguished Names" nach X500 oder spezielle 
Arzt-/Padentenindices) 

- Abfragen der Zusdmmung von Arzt und Patient (Anspruch 1) 

50 - bei Erteilung der Zustimmung: Verschlusselung des Session Keys mit dem jeweihgen privaten Schlussel von 

Arzt und Patient (Anspruch 5 und 6 sowie 12) 

- Zusammenfugen der Komponenten zu einem Session-Request (nach Anspruch 3 ff) 

- Signieren des Session-Request mit dem (unverschliisselten) Session-Key (Anspruch 13) 

55 [0138] Erweiterung: 

Wenn der https-Clienf-Schlussel im Session-Request ubertragen werden soli, so muB das Applet diesen vom Browser ab- 
rufen (Anspruch 14 ff, insbesondere 17) 
[0139] Erweiterung: 

Gegebenenfalls werden noch weitere Informationen zur Spezifikation des Kontextes, wie in Anspruch 1 angefuhrt, an- 
60 gegeben 

[0140] Erweiterung: 

Das X.509-Zertifikat einer an der Authentifizierung beteiligten Person (bder mehrerer Personen), ggf. auch zugehorige 
Zertifizierungsketten, koqnen ebenfalls im Antrag mit aufgenommen werden (Anspruch 20). In diesem Fall braucht beim 
Zugriffskontrollsystem nur das entsprechende Wurzelzertifikat vorgehalten werden (vgl. Anspruch 19). Damit wird die 
65 Verantwortung, die Berechtigung einer Person, das System geqerell zu benutzen, zu priifen, von der ZugrifFspriifstelle an 
das Trust-Center abgegeben. 
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3.4.3 Session-Request 



[0141] Der erstellte Session-Request (s. Anspruch 3 fi) hat im Beispiel folgende Struktur (ohne X.509-Zertifikate nach 
Anspruch 20): 



X-+-0-+-0 


. 0- + - 


0 . 0 


. 0 




Session ID 254 


bit random 


1 1 




0 . 0 


_ i 




Session time Stamp 


1 +-0 










encrypted Session key (DESede x dccPK x patPK) 












Doctors Data: 




1 +-0 


2- + - 


0.2 


o 




Subject DN 






+ - 


0.2 


1 


— 


Issuer DN 








0 . 2 


2 




Serial Number 






+- 


o!2 


3 




Fingerprint 














Patients Data: 




1 +-0 


3-+- 


0.3 


0 




Subject DN 






+- 


0.3 


1 




Issuer DN 






+- 


0.3 


2 




Serial Number 






' +- 


0.3 


3 




Fingerprint 




1 +-0 


4-+- 


0.4 


0 




SessionlDblock 


signed (docPK) 




+ - 


0.4 


1 




SessionlDblock 


signed (patPK) 


+-1 


Bag Seal: 


MD5 


of 0 encrypted 


with session Key 
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[0142] Diese Struktur kann z. B. in ASN.l (siehe [X.680]) dargestellt werden, in Base 64 kodiert und dann als Query 30 
an eine URL angefugt und so via http(s) an das Zugriffskontrollsystem ubertragen werden. 

3.4.4 Authentitatsprufung durch das Zugriffskontrollsystem 

[0143] Das Zugriffskontrollsystem dekodiert die query: 35 



45 
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raw DER-structure as Hex-Du.7ip: 

00 01 02 03 04 05 06 07 - 08 09 OA OB OC 00 OE OF 0123456789ABCDEF 



00000000 

00000010 

00000020 

00000030 

00000040 

00000050 

00000060 

00000070 

00000080 

00000090. 

OOOOOOAO 

0O0OOOBO 

0OOOO0CO 

OOOOOODO 

00O0OOEC 

00OOOOFO 

00000100 

00000110 

00000120 

00000130 

00000140 

00000150 

00000160 

00000170 

00000180 

000001S0 

OOOOOIAO 

000001BO 

000001CO 

oooooiDO 

000001E0 
000001FO 
00000200 
00000210 
00000220 
00000230 
00000240 
00000250 
00000260 



30 82 
30 97 
70 E3 
30 31 
30 04 
81 BB 
3D 48 
97 FA 
AB AD 
6E 20 
6D 65 
73 20 
7 3 65 
37 43 
4 4 6F 
6D 6F 
6S 6D 
5E 9A 
30 81 
20 42 
72 65 
67 20 
65 66 
62 65 
13 38 
20 50 
64 65 
3D 64 
04 10 
E5 02 
32 12 
A6 8 9 
5F F4 
A4 4C 
A4 70 
31 91 
97 94 
BF 2 6 
B8 36 



02 67 
3C 14 
5F AC 
30 34 
4 0 02 
AO 69 
34 BA 
25 BB 
39 30 
4A 6F 
69 6E 
4A 56 
6E 2C 
4E 3D 

63 74 
2C 4F 
6F 2C 
5F 89 
AF 13 
6C 3F 
73 73 
73 70 
61 6E 
72 67 
43 4E 
61 74 
6D 6F 
65 6D 

64 57 
30. 81 
28 3C 
3F 44 
85 5E 
6D 07 
5D 04 
97 Dl 
6A 2C 
EE AD 
50 48 



30 82 02 51 
20 F2 OB 12 
D4 35 BA 67 
30 32 31 31 
F2 4 3 E7 9F 
6E DC 5D OB 
25 EB 2D F3 
5D 41 5F 44 
81 9A 13 47 

68 ,6E 73 65 

73 63 68 61 
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[0144] Daraus ergibt sich die ASN.l-Struktur, die die Komponenten des Session-Requests offenlegt (vgl. ASN.l- 
45 Struktur wie oben angegeben): 



50 



55 



60 



65 
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ASNl-Structure of Request: 

0:d=0 hl=4 1= 615 cons: SEQUENCE 
4:d=l- hl=4 1= 5 93 cons: SEQUENCE 
8:d=*2 hl=2 1= 55 cons: SEQUENCE 

hl=2 1= 32 P rim: OCTET STRING 

65'd-2 M-"? ,~ i! Prlm: GENERALI ZEDTIME : 20010402115953 + 0200 
2 hl=2 1= 64 prim: OCTET STRING 
131:d-2 hl=3 1= 154 cons: SEQUENCE 
134:d-3 hl=2 1= 71 prim: PRINTABLESTRING 

CN=Johann Johnseder, 
om . ° =G ^ e i nscha ftspraxis JVX,L=Anderhausen, ST=bbb,C=de 
-iU/:d-3 hl=2 1= 55 prim: PRINTABLESTRING 

^_o N ~^"" eb Demo Doctor s CA,OU=demo,0=IP-Web, ST=demo,C=de 
270 -d"? h^ = | j = Pr - m: INTEGER : 3AB4EC35 

ooo 1= 16 P rim: OCTET STRING 

288:d=2 hl=3 1= 175 cons: SEQUENCE 
2 91 :d- 3 hl=2 1= 91 prim: PRINTABLESTRING 
CN=Benjamin Bl?mchen, 

Q=Interessenvereinigung sprechender Elefanten, 
L=Bibberberg, ST=ppp, C=de 
384:d=3 hl=2 1= 56 prim: PRINTABLESTRING 

44 ,. H _^ N= ^"^ Dem ° ^tients CA, OU=demo, 0=IP-Web, ST-demo, C=de 

Al'i-l ^ = A Pr . m: INTEGER : 3AB4EEBA 

4 4B.d-3 hl=2 1= 16 prim: OCTET STRING 

4 66:d=2 hl=3 1= 132 cons: SEQUENCE 

c,! : ^ =3 , !? 1=2 1= 64 P rira: OCTET STRING 

coi IT 1= 64 P rim: OCTET STRING 

601:d=l hl=2 1= 16 prim: OCTET STRING 



[0145] Es liegen nun die Informationen vor, um die tjberprtifung der Authentizitat vorzunehmen: 

- aus den Identitatsinformationen von Arzt und Patient sowie deren Zertifizierem werderi die entsprechenden Zer- 
tifikate ennittelt 

- tFber Seriennummer und Fingerprint der Zertirikate wird ein erster Echtheitstest vorgenommen (Anspruch 18) 35 

- Die Zertifikate enthalten den jeweiligen ofifentlichen Schlussel 

- der verschlusselt vorliegende Session Key wird mit den beiden offentlichen Schliisseln von Arzt und Patient ent- 
schlusselt (Anspruch 12): 

Dann und nur dann wenn sowohl Arzt als auch Patient mit dem richtigen privaten Schlussel gearbeitet haben, laBt 
sich so der urspriingliche Session Key wiederherstellen 40 

- Es wird der Hash-Wert des Session-Requests gebildet und mit dem wiederhergestellten Session Key verschlus- 
selt. Wenn das Ergebnis mit dem ubermittelten Wert ("Bag Seal") identisch ist, dient das als Beweis fur eine kor- 
rekte Authentifizierung (Anspruch 13) 

[0146] Der so wiederhergestellte Session Key kann bei Bedarf weiter verwendet werden, um die weitere Kommunika- 45 
tion zu verschliisseln, so daB nur die berechtigten Parteien daran teilnehmen konnen (Anspruch 15). 
[0147] Erweiterung: 

Das Zugriffskontrollsystem kann den ssl-Schliissel des Clients aus der Netwerksoftware abrufen, wenn diese Informa- 
tion nicht Bestandteil des Session-Requests ist. Damit entfallt clientseitig die Notwendigkeit, dafi das Applet auf den 
https-Schlussel zugreifen muB. Dies wiederum vereinfacht die Verwendung von Standardbrowsern auf Clientseite. 50 

3.4.5 Freigabeserver 

[0148] Der entschliisselte Session-Key, die ssl-Identitat des PC in der Arztpraxis und die anderen Informationen des 
Session-Requests werden an den Freigabeserver (nach Anspruch 23) Ubermittelt. Hierzu kann z. B. das Zugriffskontroll- 55 
system eine https- Verbindung zu diesem aufbauen (vgl. Anspruch 24, 26, 27). Der Freigabeserver speichert die Informa- 
tionen, um sie fur den Fall eines Datenabrufs auswerten zu konnen. 

[0149] Daraufhin ubermittelt das Zugriffskontrollsystem eine Erfolgsmeldung an den Browser beim Arzt, die sinnvoll- 
erweise einen Hyperlink auf den Freigabeserver (bzw. je eihen Link auf jeden Server, wenn Datenbestande an verschie- 
denen Stellen vorliegen) enthalt. AuBerdem konnen die Links (gemaB Anspruch 28 und 29) Query-\&riablen enthalten, 60 
die zur weiteren Spezifikation der verlangten Daten dienen (z. B. Namen des Patienten, um Verwechslungen bei kurz 
aufeinanderfolgenden Abfragen zu vermeiden). 

[0150] Durch Aktivieren der Links im Browser (Anspruch 41 ff) sendet das Arztsystem nun einen http(s)-Request an 
den Freigabeserver. Dieser ruft die gewiinschten Daten aus der Datenbank ab und erhalt von dieser (ggf . auch vorher) die 
fur den Zugriff erforderlichen Voraussetzungen (Anspruch 30 ff). Diese Voraussetzungen vergleicht er mit den gespei- 65 
cherten Daten aus dem vorher ubermittelten Session-Request (Anspruch 30). 

[0151] Des weiteren ennittelt der Freigabeserver die ssl-Identitat des Arzt-PC und vergleicht sie mit der vom Zugriffs- 
kontrollsystem ubermittelten (Anspruch 35, 36). Damit wird verhindert, daB ein unbefugter Benutzer mit einer aufge- 
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zeichneten ZugrifTssequenz, die er zwar nicht analysieren, aber 1 : 1 wiedergeben kann, Datenzugriff erhalt ("replay-at- 
tack"). 

[0152] Wenn alle Priifungen erfolgreich sind, iibertragt der Freigabeserver die erbetenen Daten als http(s)-Response an 
den Arzt-PC. Dieser Response kann weitere Hyperlinks zu anderen Daten auf dem gleichen oder einem anderen System 
5 enthalten (Anspruch 41 ff). Sofera fur einen Abruf bestimmte Inhalte einer URL-query erforderlich sind, werden diese 
im Response weitergereicht ("state-Management" im http-Protokoll, vgl. auch Anspruch 28 und 29). 

3.5 Erganzungen und Erweiterungen 

to [0153] Wichtige Variationen der Erfindung, die hier im Ausfuhrungsbeispiel nicht oder nur andeutungsweise erfaBt 
sind, werden im Folgenden noch angefuhrt. 

3.5.1 Komplexe Verschliisselung in der Datenubertragung 

15 [0154] Im beschriebenen Beispiel erfolgt die Ubertragung zwischen freigebender Stelle iiber https, also yerschliisselt 
mit dem ssl-Client-Schliissel des Arzt-PC. Dieser Schlussel ist ublicherweise auf dem Rechner in einer Datei abgelegt 
und ist damit unbefugten Zugriffen z. B. bei der Rechneradministration ausgesetzt ("man-at-the-end-attack"). Dieser 
Schlussel bietet also bei weitem nicht die Sicherheit wie die Smart-Card-basierten Schlussel zur personlichen Authenti- 
fizierung. 

20 [0155] Alternative Schlussel, die diesen Mangel beheben konnen, sind in Anspruch 37/38 beschrieben. Insbesondere 
der Session Key kame hierfur in Frage. Die meisten dieser Losungen haben jedoch den Nachteil, daB clientseitig keine 
Standardbrowser mehr verwendet werden konnen. 

3.5.2 Schreibender Datenzugriff 

25 

[0156] Die bisherigen Beschreibungen des Ausfuhrungsbeispiels beziehen sich teilweise implizit auf lesenden Zugriff . 
[0157] Die Ablaufe fur schreibenden Zugriff (Daten anlegen, andern, loschen, Rechte andem) sind weitgehend iden- 
tisch. Lediglich der Freigabeserver und die Kommunikation mit der Datenbank muB entsprechend angepaBt werden. Als 
Kommunikationsprbtokoll mit dem Client kann weiterhin http(s) verwendet werden, das durch Formulare und POST-Re- 
30 quests eine Dateneingabe ermoglicht. 

3.5.3 Verzeichnisdienste fur Zertifikate 

[0158] Das beschriebene Ausfuhrungsbeispiel geht nicht darauf ein, woher die Zertifikate kommen, die fur die Authen- 
35 titatsuberprufung eingesetzt werden. Neben der Ubermittlung mit dem Session Request nach Anspruch 20 sind die Va- 
riationen in Anspruch 21 und 22 dargelegt. 

[0159] Eine sinnvolle Moglichkeit ware etwa, wenn die Ausgabe der Smart-Cards von einem Trust-Center erfolgt, das 
nicht nur die Identitat des Inhabers, sondem auch weitergehende Voraussetzungen zur Teilnahme am System (z. B. bei 
einem Arzt die fachliche Zulassung) pruft und festhalt. Diese Informationen konnen dann - zusammen mit dem Zertifikat 
40 - von diesem Trust-Center iiber LDAP (ggf. iiber eine gesicherte Verbindung) dem Zugriffskontrollsystem ubermittelt 
werden. ' 

[0160] Bei einem Ausbau des Systems konnen mehrere unabhangige Stellen diese Zertifizierung iibernehmen (z. B. 
Krankenkassenfilialen fur Patienten). In diesem Fall empfiehlt sich ein mehrstufiges Zertifzierungsverfahreh, wie es in 
[X.509] vorgesehen und in Anspruch 18 ff angefuhrt ist. 
45 . 

3.5.4 Verzeichnis der verfugbaren Daten 

[0161] Die beschriebene Realisierung geht davon aus, daB letztlich erst das datenhaltende System detaillierte Informa- 
tionen besitzt, welche Daten zu einem spezifischen Kontext zur Verfugung stehen. 
50 [0162] Diese Information kann aber auch anders iiber die einzelnen Systemkomponenten (Zugriffskontrolle, Freigabe, 
mehrere datenhaltende Stellen, dedizierte Verzeichnisse) verteilt werden. Auch eine Kombination mit anderen Datenbe- 
standen (Verzeichnisdienst nach vorgehendem Abschnitt, Zugriffskontrolliste) ist denkbar. 

[0163] Die detailherten Variationsmoglichkeiten des Datenbankdesigns ergeben sich aus praktischen und sicherheits- 
politischen Erwagungen und gehen iiber den in diesem Patent beanspruchbaren Rahmen hinaus. 

55 

3.5.5 Iterative Zustimmung zur Datenfreigabe 

[0164] In der Zeichnung zum Gesamtsystem ist ein "Selection Key" angedeutet, der verwendet wird, wenn der Patient 
explizite Zustimmung. zur Offenlegung einer beschrankten Teilauswahl aus alien verfugbaren Informationen erteilen 
60 . soli. In den weiteren Erlauterungen wurde aus Griinden der Ubersichtlichkeit hierauf nicht weiter eingegangen. 

[0165] Hierbei handelt es sich um kontextspezifische Informationen (nach Anspruch 1), die durch mehrere Anforde- 
rungszyklen (nach Anspruch 41) ermittelt werden. 

[0166] Der Selection Key iibernimmt dabei die Rolle des Session Key; es wird gleichsam durch Iteration nach An- 
spruch 41 ein neuer Kontext nach Anspruch 1 erofFnet. 

65 

3.5.6 Vertretung von Pefsonen 



[0167] Anspruch 45 erwahnt verschiedene Vertretungskonstellationen. Beispiele hierfur konnen sein: 
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- nicht ein Arzt selber, sondem ein Assistent ruft Daten ab 

- Patienten werden von Erziehungsberechtigten oder einem Vormund vertreten 

- Ein "Notzugang" ermoglicht den Zugriff auf Daten von Patienten ohne BewuBtsein 

- Zugriffsrechte werden nicht einer Person, sondern einer Organisation gewahrt 

- Zugriffsschliissel konnen in einer Software, z. B. der Praxissoftware des Arztes, hinterlegt sein 

- Applikationen in anderem als dem hier beispielhaft dargestellten Kontext konnen andere Vertretungsmoglichkei- 
ten beinhalten 

[0168] Welche Vertretungsmoglichkeiten zugelassen sind ist eine Frage der Sicherheitspolitik. 

3.5.7 Festlegung einer Sicherheitspolitik 

[0169] Viele Entscheidungen uber die Implementierung konnen nicht nach technischen Erwagungen auf der Suche 
nach einer "bestmoglichen Sicherheit" getroffen werden, sondern entstehen durch Abwagung zwischen Sicherheitstech- 
nik, rechtlichen Anforderungen, Kompatibilitat mit bestehenden Systemen oder Bedienbarkeit. Selbst subjektive Ver- 
trauens-"Gefuhle" miissen hier mit einbezogen werden. Diese Erwagungen entziehen sich naturgemaB der technischen 
Natur eines Patentes, weshalb in dieser Beschreibung derartige Entscheidungen und Varianten regelmaBig often gelassen 
werden. . 

[0170] Aufbauend auf dem hier beschriebenen Grundgeriist konnen Anpassungen an eine vorgegebene Sicherheitspo- 
litik - bei gegebenen Anforderungen - durch einen geiibten Fachmann vorgenommen werden. 

Patentanspriiche 

1. Verfahren zur Zugriffsteuerung auf elektronisch gespeicherte Daten in verteilten heterogenen Umgebungen, ge- 
kennzeichnet dadurch, daB 

die Freigabe des Datenzugriffs durch mehrere Personen erfolgt 

eine dritte Stelle zur Freigabepriifung zwischen Datenabrufstelle und Datenspeicherstelle eingeschaltet ist 

fur die Uberprufung der Authentizitat der Freigabe erteilenden Personen kryptographische Verfahren mit offentli- 

chen und privaten Schlusseln verwendet werden 

die Kontextsituation der Personen im Rahmen der Datenanforderung mit in den Umfang der erteilten Freigabe ein- 
flieBen kann. 

2. Verfahren nach Anspruch 1, gekennzeichnet dadurch, daB 

fur die Daten ubertragung geeignete Netzwerkprotokolle verwendet werden konnen, 

fur die Datenubertragung die Internet-Protokoll-Familie (insbesondere IP, TCP, UDP) verwendet werden konnen, 
. fur die Datenubertragung das Internet verwendet werden kann. 

3. Verfahren nach Anspruch 1, gekennzeichnet dadurch, daB fur jeden Vorgang, bei dem eine Freigabe angefordert 
wird 

ein spezielles digitales Freigabeobjekt ("Authentifizierungsantrag") zur Kommunikation der beteiligten Systeme 
untereinander erstellt wird 

das Freigabeobjekt ein eindeutiges Merkmal des Authentifizierungsvorganges enthalt 
das Freigabeobjekt weitere Daten uber den Authentifizierungskontext enthalten kann 

4. Verfahren nach Anspruch 3, gekennzeichnet dadurch, daB . 

das Freigabeobjekt einen zufallig generierten oder anderweitig als eindeutig geltenden digitalen Schliissel zur Iden- 
tifikation des Authentifizierungsvorgangs enthalten kann 

das Freigabeobjekt einen Zeitstempel des Authentifizierungsantrages enthalten kann 

das Freigabeobjekt Angaben uber den zeitlichen Geltungsbereich der Authentifizierung enthalten kann 

5. Verfahren nach Anspruch 1, gekennzeichnet dadurch, daB die am Authentifizierungskontext beteiligten Personen 
durch asymmetrische digitale Schlusselpaare identifziert sind 

6. Verfahren nach Anspruch 5, gekennzeichnet dadurch, daB eines der folgenden Verfahren fur die asymmetrischen 
digitalen Schliissel verwendet wird: 

PxSA 
DSA 

elliptische Funktionen 

7. Verfahren nach Anspruch 5, gekennzeichnet dadurch, daB der private Schliissel einer an der Authentifizierung 
beteiligten Person auf einer physikalisch eigenstandigen Einheit gehalten wird, die 

von der Person mitgefuhrt werden kann 

vom System, das an der Datenabrufstelle zur Anforderung der Datenfreigabe verwendet wird, getrennt werden kann 
mit unterschiedlichen Systemen zur Anforderung der Datenfreigabe verwendet werden kann 
die erforderlichen Verschlusselungsoperationen selbst vornehmen kann, so daB der private Schliissel der Person 
nicht an das System zur Anforderung der Datenfreigabe ubertragen werden muB 

8. Verfahren nach Anspruch 7, gekennzeichnet dadurch, daB diese eigenstandige Einheit eine handelsiibliche 
Smart-Card (integrierter Schaltkreis, eingebaut in ein Kunststoffgehause im Scheckkartenformat) mit Kryptopro- 
zessorist 

9. Verfahren nach Anspruch 5 bis 8* gekennzeichnet dadurch, daB der private Schliissel durch ein biometrisches 
Merkmal vor unbefugter Verwendung geschiitzt ist 

10. Verfahren nach Anspruch 9, gekennzeichnet dadurch* daB als biometrisches Merkmal eines oder mehrere der 
Folgenden verwendet werden konnen: 

individueller Fingerabdruck 
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individuelle Iris-Musterung 
individuelle Gesichtsziige 
individuelle Sprache 
genetische Muster 

5 Muster aus der Gen-Exprimierung, insbesondere RSA und Proteine 

11. Verfahxen nach Anspruch 1 bis 10, gekennzeichiiet dadurch, daS fur die Identifikation des Authentifizierungs- 
kontextes eine eindeutige binare Sequenz als "Session Key" verwendet wird 

12. Verfahren nach Anspruch 11, gekennzeichnet dadurch, daB der Session Key mit privaten Schliisseln von am 
Kontext beteiligten Personen verschliisselt wird 

10 13. Verfahren nach Anspruch 3, 11 und 121 gekennzeichnet dadurch, daB die Integritat des Authentifizierungsan- 

trages dadurch gewahrleistet wird, daB der gesamte Antrag oder Teile davon mit dem Session Key oder einer davon 
abgeleiteten binaren Sequenz digital signiert wird 

14. Verfahren nach alien bisher genannten Anspriichen, gekennzeichnet dadurch, daB das System, das zur Anfor- 
derung der Datenfreigabe verwendet wird, Bestandteil des Authentifizierungskontextes ist 
15 15. Verfahren nach Anspruch 14, gekennzeichnet dadurch, daB 

das anfordernde System gegeniiber dem priifenden System durch ein unabhangiges asymmetrisches Schliisselpaar 
iden tifiziert werden kann 

die Kommunikation zwischen anforderndem System und priifendem System verschliisselt erfolgen kann 

16. Verfahren nach Anspruch 15, gekennzeichnet dadurch, daB die Kommunikation zwischen anforderndem Sy- 
20 stem und priifendem System iiber eine Variante des Protokolls ssl oder tls ("secure Socket Layer") erfolgen kann 

17. Verfahren nach Anspruch 16, gekennzeichnet dadurch, daB zur Authentifizierung des Gerates gegeniiber der 
priifenden Stelle und zur Verschliisselung der Datenubertragung das Protokoll https ("http oyer ssl") verwendet wird 

18. Verfahren nach den bisher genannten Anspriichen, gekennzeichnet dadurch, daB die tjberprufung der Giiltig- 
keit von Authentizitatsbehauptungen anhand einer dieser Moglichkeiten erfolgt: 

25 eines bei der priifenden Stelle hinterlegten offentlichen Schliissels als Gegenstuck zum privaten Schliissel des zu au- 

thendfizierenden Akteurs 

der elektronischen Bescheinigung einer vertrauenswurdigen Instanz ("Trust Center"), deren offendicher Schliissel 
bei der priifenden Stelle vorliegt 

der elektronischen Bescheinigung einer vertrauenswurdigen Instanz ("Trust Center"), deren Authentizitat von einer 
30 Kette aus Authentizitatsbescheinigungen besteht, wobei am Anfang der Kette eine Instanz steht, deren offendicher 

Schlussel bei der priifenden Stelle vorliegt 

19. Verfahren nach Anspruch 18, gekennzeichnet dadurch daB fur Authendzitatsprufung die Verfahren verwendet 
werden, wie sie in ISO X.509 festgelegt sind 

20. Verfahren nach Anspruch 18 und 19, gekennzeichnet dadurch, daB zur Authendfikadon erforderliche Zusatzin- 
3S formationen (z. B. X.509-Zertifikate, Zertifikatsketten oder vergleichbare Daten) zusammen mit dem Freigabean- 

trag ubermittelt werden konnen 

21. Verfahren nach Anspruch 18, 19 und 20, gekennzeichnet dadurch, daB die zur Authendzitatsprufung erforder- 
lichen offentlichen Schlussel sich in einer Datenbank an einer der folgenden Standorte befinden: 

der priifenden Stelle selbst 
40 innerhalb der unmittelbaren, kontrollierbaren Sicherheitssphare der priifenden Stelle 

einer offentlich verfugbaren Stelle, zu der von der priifenden Stelle aus eine unverfalschbare Datenverbindung be- 
steht 

22. Verfahren nach Anspruch 21, gekennzeichnet dadurch, daB die "Qbertragung zwischen der priifenden Stelle und 
der Datenbank durch eines der folgenden standardisierten Protokolle erfolgt 

45 ITU-T- Empfehlung X500 ff. 

Lightwighted Directory Access Protocol (LDAP) 

23. Verfahren nach einem der bisher genannten Anspriichen, gekennzeichnet dadurch, daB 

die Priif ung der Authentizitat der Freigabe erteilenden Akteure durch eine andere Stelle erfolgen kann als der, die 
die Daten frei gibt 

50 die Freigabe der Daten durch eine andere Stelle erfolgen kann als der, die die Daten gespeichert hat 

24. Verfahren nach 23, gekennzeichnet dadurch, daB 

die priifende Stelle an die freigebende Stelle einen geeigneten Datensatz ubertragt, der der freigebenden Stelle die 
* Evaluation des Kontextes ermoglicht ("push Session Request") 

dieser Datensatz an der freigebenden Stelle gespeichert werden kann, bis eine Anforderung von der abrufenden 
55 Stelle erfolgt 

und/oder aufgrund des Freigabedatensatzes bereits Daten an die abrufende Stelle gesandt werden konnen 

25. Verfahren nach 23, gekennzeichnet dadurch, daB die freigebende Stelle von der priifenden Stelle einen geeig- . 
neten Datensatz abruft, der der freigebenden Stelle die Evaluation des Kontextes ermoglicht, sobald eine Anforde- 
rung zur Datenfreigabe an sie geri'chtet wird ("pull Session Request") 

60 26. Verfahren nach Anspruch 23 bis 25, gekennzeichnet dadurch, daB 

die Kommunikation zwischen freigebender und priifender Stelle mit wechselseitiger kryptographischer Authendfi- 
zierung erfolgen kann 

die Kommunikation zwischen freigebender und datenhaltender Stelle mit wechselseitiger kryptographischer Au- 
thendfizierung erfolgen kann 
65 die Kommunikation zwischen freigebender und priifender Stelle verschliisselt erfolgen kann 

die Kommunikation zwischen freigebender und datenhaltender Stelle verschliisselt erfolgen kann 

27. Verfahren nach Anspruch 26, gekennzeichnet dadurch, daB 

die Kommunikation der benannten Systeme iiber ssl (oder tls) erfolgt 
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die Kommunikation der benannten Systeme iiber https erfolgen kann 

28. Verfahren nach Anspruch 23, gekennzeicb.net dadurch, daB anstatt oder erganzend zu einer djrekten Kommuni- 
kation zwischen freigebender und priifender Stelle die priifende Stelle ein geeignetes, von der priifenden Stelle si- 
gniertes, kryptographisches Datum ("ticket" oder "token") an die anfordemde Stelle ubermittelt, das die Richtigkeit 

der Authentifizierung beweist und mit dem sich dann die anfordemde Stelle der freigebenden Stelle gegeniiber aus- 5 
weisen kann 

29. Verfahren nach Anspruch 28, gekennzeichnet dadurch, daB dieses Token tiber geeignete http-state-Manage- 
ment-Technologien iibertragen wird, insbesondere 

im Browser der anfordemden Stelle gespeicherte Variableninhalte ("Cookies") 

von Requestzyklus zu Requestzyklus weitergereichte URL-Query- bzw. HTTP-POST- Variablen-Inhalte to 

30. Verfahren nach bisher genannten Anspriichen, gekennzeichnet dadurch, daB 

die freigebende Stelle iiber eine "Zugriffskontrolliste" verfugt, die angibt, wer unter welchen Voraussetzungen Zu- 
griff mit welcher Berechtigung auf welche Daten hat 

der Inhalt des Zugriffsantrages, insbesondere auch die entsprechenden Informationen iiber den Zugriffskontext, mit 
den Vorgaben aus der Zugriffskontrolliste verglichen werden und daraus die zugestandenen Zugriffsrechte abgelei- is 
tet werden 

31. Verfahren nach Anspruch 30, gekennzeichnet dadurch, daB die freigebende Stelle die Zugriffskontrollinforma- 
tionen bei Bedarf von dem datenhaltenden System abruft 

32. Verfahren nach Anspruch 30, gekennzeichnet dadurch, daB die datenhaltende Stelle die Zugriffskontrollinfor- 
mationen direkt mit den erbetehen Daten - noch vor der Berechtigungspriifung - an die freigebende Stelle ubermit- 20 
telt 

33. Verfahren nach Anspruch 32, gekennzeichnet dadurch, daB 

das datenhaltende System die erbetene Antwort an das freigebende System im HTML-Format ubermittelt 

die Zugriffskontrollinformationen als spezifische, im Browser nicht storende oder vom Freigabesystem zu entfer- 

nende HTML-Tags ubermittelt werden 25 

34. Verfahren nach Anspruch 32, gekennzeichnet dadurch, daB 

das datenhaltende System die erbetene Antwort an das freigebende System im XML-Format ubermittelt 
die Zugriffskontrollinformationen als eigens definierte XML-Elemente oder -Attribute ubermittelt 

35. Verfahren nach bisher genannten Anspriichen (insbesondere 14 bis 17), gekennzeichnet dadurch, daB 

der Zugriff auf freigegebene Daten nur von dem System aus erfolgen kann, das die Freigabeanforderung erstellt hat 30 
die Authentifizierungsinformationen des Zugriff verlangenden Systems vom Authentiztat priifenden System an das 
freigebende System mit ubermittelt werden 

diese Authentifizierungsinformationen netzwerkspezifische Daten (z. B. IP-Adresse, DNS-Namen) enthalten kon- 
nen 

diese Authentifizierungsinformationen Bestandteile oder eindeutige Merkmale eines kryptographischen Schliissel- 35 
paares enthalten konnen 

36. Verfahren nach Anspruch 35, gekennzeichnet dadurch daB 

die priifende Stelle an die freigebende Stelle den ssl-Client-Schliissel der anfordemden Stelle ubermitteln kann 
die freigebende Stelle mit der anfordemden Stelle iiber ssl oder tls (ggf. als https) kommunizieren kann 

37. Verfahren nach bisher genannten Anspriichen, gekennzeichnet dadurch, daB die Kommunikation zwischen der 40 
freigebenden Stelle mit der anfordemden Stelle auf Netzwerk- und/oder Datenebene mit (unter anderem) einem 
oder mehreren der folgenden Schliissel verschlusselt und/oder authentifiziert werden kann: 

Session-Key der kontextbezogenen Anforderung 

Schlusselpaar einer oder mehrerer der am Kontext der Anforderung beteiligten Personen 

Schliisselpaar des zur Anfordemng verwendeten Systems 45 
Schlusselpaar des freigebenden Systems 

38. Verfahren nach Anspruch 37, gekennzeichnet dadurch, daB anstatt einer direkten Verschliisselung auch eines 
der in der Kryptographie bekannten Hybridverfahren verwandt werden kann 

39. Verfahren nach bisher genannten Anspriichen, gekennzeichnet dadurch, daB 

freigebende und datenhaltende Stelle in einer Firewall-Topologie eingebaut sind 50 
hierbei die datenhaltende Stelle im geschutzten intemen Bereich und die freigebende Stelle in der "DMZ" ("entmi- 
litarisierten Zone") der Firewall liegen kann 

40. Verfahren nach Anspruch 39, gekennzeichnet dadurch, daB die freigebende Stelle als "Application level Proxy" 
auf Schicht 7 des OSLReferenzmodells realisiert ist 

41. Verfahren nach bisher genannten Anspriichen gekennzeichnet dadurch, daB 55 
die Freigabe der Daten in mehreren Anforderungszyklen erfolgen kann 

die Freigabe anfordemden Personen dabei weitere Kontextinformationen nachliefern konnen 
die Freigabe erteilende Stelle Informationen iiber verfiigbare Daten und/oder erforderliche weitere Kontextinforma- 
tionen an die Freigabe anfordemde Stelle senden kann 

durch wiederholte Zyklen der Umfang der freigegebenen Daten erweitert oder konkretisiert werden kann 60 

42. Verfahren nach Anspruch 41 gekennzeichnet dadurch, daB 

zur Vermittlung zwischen den Zyklen Hyperlinks, wie sie etwa aus dem WWW bekannt sind, verwendet werden 
konnen 

diese Hyperlinks statisch festgelegt oder dynamisch von den beteiligten Systemen generiert werden konnen 

43. Verfahren nach Anspruch 41 und 42, gekennzeichnet dadurch, daB die Hperlinks in Dokumenten folgender 65 
Struktur enthalten sein konnen: 

Hypertext Markup Language (HTML) 
Extended Markup Language (XML) 
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44. Verfahren nach Anspruch 41 bis 43, gekennzeichnet dadurch, daB zur tjbertragung wahrend der Anforderungs-' . 
zyklen eine Variante des Intemet-Protokolls http (insbesondere auch https) verwendet wird 

45. Verfahren nach bisher genannten Anspriichen, gekennzeichnet dadurch, daB 

an die S telle von natiirlichen Personen auch andere juristische Personen treten konnen 

5 Personen auch andere vertreten konnen 

die Rolle von Personen, die im eigenen Namen oder in Vertretung handeln, von datentechnischen Systemen iiber- 
nommen werden kann, die innerhalb des beschriebenen Verfahrens das gleiche Verhalten zeigen, und deren Funk- 
tion davon abhangig ist, daB die vom System vertretene Person diese Handlung durch eine WillensauBerung dem 
System gegeniiber kundgetan hat. 

to 
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Zeichnung 2 - Beispiel der Authentifizierungsoberflache (Entwicklungsinstallation): 
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Zeichnung 3 - Zertifikatsverwaltung in einem Standard-Browser: 
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